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(54) System and method for using a window mechanism to control multicast data congestion 



(57) A system and method for using a window mech- 
anism to control transmission of a multicast'in a compu- 
ter network to curb congestion. In one embodiment, the 
system includes: (1) a packet monitor that tracks, for 
each receiver of the multicast, unacknowledged packets 



transmitted to each receiver and (2) a multicast manag- 
er, associated with the packet monitor, that controls 
transmission of further packets of the multicast to pre- 
vent the unacknowledged packets transmitted to any of 
each receiver from exceeding a maximum number as- 
sociated with each receiver. 
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Description 

Technical Field of the Invention 

[0001] The present invention is directed, in general, 
to computer networks and. more specifically to a sys- 
tem and method for using a window mechanism to con- 
trol data congestion brought about Dy h multicast in a 
computer network. 

Background of the Invention 

[0002] Until recently, communcaiion systems built 
around the Open Systems Interconnect (OSI ) reference 
model or the Internet architecture were designed to sup- 
port point-to-point (unicast) services Presently one of 
the most pressing needs for enhancec communication 
protocols comes from multipoint, or group, applications 
The multipoint applications encompass a wide range of 
applications including software distribution, replicated 
database update, command and control systems and 
audio/video conferencing. 

[0003] A multicast is generally the transmission of da- 
ta from a single sender to multiple receivers. Multicast- 
ing provides an efficient method of disseminating data 
from a sender to a group of receivers. Instead of sending 
a separate copy of the data to each individual receiver, 
the sender sends a single copy to all the receivers. A 
multicast "tree" is set up in the data communication net- 
work with the sender as the "root" node and the receiv- 
ers as the "leaf" nodes. Data generated by the sender 
flows through the multicast tree, transversing each tree 
edge exactly once. For a better understanding of multi- 
casting, see "Multipoint Communication: A Survey of 
Protocols, Functions, and Mechanisms" by Christophe 
Dot et al., IEEE Journal on Selected Areas in Commu- 
nications, Vol. 15, No. 3, April 1997, pp. 277-290, which 
is herein incorporated by reference. 
[0004] The reliable distribution of data using the mul- 
ticast tree in an unreliable network is not guaranteed. 
Existing protocols [e.g. t Internet Protocol(IP), Connec- 
tionless Network Protocol (CLNP) and User Datagram 
Protocol (UDP)] are sufficient for those applications that 
can be satisfied by a connectionless, relatively unrelia- 
ble, multicast communication support. A more reliable 
multicast, however, is required in situations such as in 
a distributed interactive simulation (DIS) environment or 
in collaborative applications. Reliable multicast proto- 
cols are not new in the area of distributed and satellite 
broadcast systems. Most of these protocols, however, 
apply to local area networks and do not scale well in 
wide area networks. 

[0005] To address the need for reliable multicast in 
wide area networks, many transport protocols have 
been proposed and developed. Most of the focus, how- 
ever, of the work done in developing reliable multicast 
schemes and protocols has concentrated primarily on 
methods for error recovery. For example, one particular 



transport protocol that has been developed to address 
the need for more reliable data transmission is the Re- 
liable Multicast Transport Protocol (RMTP). RMTP is de- 
signed to provide sequenced, lossless delivery of a data 

5 stream, or packets, from one sender to a group of re- 
ceivers. RMTP is based on a multi-level hierarchical ap- 
proach in which the receivers are grouped in a hierarchy 
of local regions. This hierarchical approach allows for 
the error recovery methodology to be scalable. A des- 

10 ignated receiver (DR) in each local region is responsible 
for sending acknowledgments (ACKs) periodically to the 
sender, for processing ACKs from the receivers in its 
region and for retransmitting lost packets to the corre- 
sponding receivers. For a more detail understanding of 

is RMTP, see "Reliable Multicast Transport Protocol 
(RMTP)" by Sanjoy Paul et al, IEEE Journal on Select- 
ed Areas in Communications, Vol. 15, No. 3, April 1997, 
pp. 407-420, which is herein incorporated by reference. 
[0006] Efforts to develop congestion control method- 

20 ologies for multicast have been directed primarily in the 
areas of audio and video multicast transmissions. With 
voice and audio multicasts, the approach to congestion 
control has been to receive less data packets, i.e., some 
of the data packets are not sent to a receiver that de- 

2S cides to ignore them, in order to reduce congestion. 
While this approach might be satisfactory in the context 
of voice and audio multicasts, e.g., with video the re- 
ceiver will still be able to form a coarse or lower resolu- 
tion picture, for reliable multicast, discarding some data 

30 packets is unacceptable. 

[0007] Accordingly, what is needed in the art are im- 
proved methods for controlling congestion that may oc- 
cur due to a multicast through a computer network. In 
particular, what is needed in the art is a method for con- 

55 gestion control in reliable multicast transport protocols. 
[0008] According to one aspect of the present inven- 
tion, there is provided a system for controlling transmis- 
sion of packets of a multicast in a computer network, 
comprising: a packet monitor that tracks, for each re- 

40 ceiver of said multicast, unacknowledged packets trans- 
mitted to said each receiver; and a multicast manager, 
associated with said packet monitor, that controls trans- 
mission of further packets of said multicast to prevent 
said unacknowledged packets transmitted to any of said 

45 each receiver from exceeding a maximum number as- 
sociated with said each receiver. The said packet mon- 
itor and said multicast manager can be associated with 
a sender of said multicast. The multicast manager can 
be capable of dynamically changing said maximum 

so number associated with said each receiver. The multi- 
cast manager can control retransmission of said unac- 
knowledged packets. 

[0009] According to another aspect of the invention, 
there is provided a method of controlling transmission 
55 of multicast in a computer network, comprising the steps 
of: tracking, for each receiver of said multicast, unac- 
knowledged packets transmitted to said each receiver; 
and controlling transmission of further packets of said 
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multicast to prevent said unacknowledged packets 
transmitted to any of said each receiver from exceeding 
a maximum number associated with said each receiver. 
The steps of tracking and controlling can be carried out 
in a sender of said multicast. The method can further 
comprise the step of dynamically changing said maxi- 
mum number associated with said each receiver, and/ 
or the step of controlling retransmission of said unac- 
knowledged packets. 

[001 0] According to a further aspect of the invention, 
there is provided a computer network, comprising: a 
multicast sender; a plurality of receivers that receive 
said multicast from said multicast sender; and a system 
for controlling transmission of a multicast in a computer 
network, including: a packet monitorthat tracks, for each 
of said plurality of receivers, unacknowledged packets 
transmitted to said each of said plurality of receivers, 
and a multicast manager, associated with said packet 
monitor, that controls transmission of further packets of 
said multicast to prevent said unacknowledged packets 
transmitted to any of said plurality of receivers from ex- 
ceeding a maximum number associated with said each 
receiver. The packet monitor and said multicast manag- 
er can be associated with a sender of said multicast. 
The multicast manager can be capable of dynamically, 
changing said maximum number associated with said 
each receiver. The multicast manager can control re- 
transmission of said unacknowledged packets. 
[0011] To address the above-discussed deficiencies 
of the prior art. the present invention provides a system 
and method that essentially establishes a multicast 
■window" to control transmission of a multicast in a com- 
puter network to curb congestion. In one embodiment, 
the system includes: (1) a packet monitor that tracks, for 
each receiver of the multicast, unacknowledged packets 
transmitted to each receiver and (2) a multicast manag- 
er, associated with the packet monitor, that controls 
transmission of further packets of the multicast to pre- 
vent the unacknowledged packets transmitted to any of 
each receiver from exceeding a maximum number as- 
sociated with each receiver. 

[001 2] The present invention therefore introduces the 
broad concept of managing multicasts by tracking un- 
acknowledged packets for each multicast receiver and 
allowing only a certain "window" of packets to remain at 
least partially unacknowledged at a given time. In this 
manner, multicast transmission of packets is done with 
separate consideration of the congestion status of the 
path of each receiver. "Tracks* or "tracking" is defined 
as "keeping count of" or "monitoring the number of." 
While each receiver has a maximum number associated 
therewith, it should be understood that the maximum 
number may be the same for two or more of the receiv- 
ers, or may be the same for all receivers, in the simplest 
case. 

[0013] In one embodiment of the present invention, 
the packet monitor establishes a token pool for each re- 
ceiver, the multicast manager preventing a number of 



tokens in each the token pool from being outside a par- 
ticular range. 

[0014] In one embodiment of the present invention, 
the token pool for each receiver is initialized with a 

s number of tokens equaling the maximum number asso- 
ciated with each receiver, the packet monitor removing 
a token from each of the token pools when a packet is 
transmitted and replacing a token in one of the token 
pools when a receiver corresponding to the one of the 

10 token pools acknowledges receiving the packet. In an 
alternative embodiment, the token pool for each receiv- 
er is initialized to zero, the packet monitor placing a to- 
ken in each of the token pools when a packet is trans- 
mitted and removing a token from one of the token pools 

is when a receiver corresponding to the one of the token 
pools acknowledges receiving the packet. Thus, the 
present invention accommodates all particular ways of 
tracking unacknowledged packets. 
[0015] In one embodiment of the present invention, 

20 the packet monitor and the multicast manager are as- 
sociated with a sender of the multicast. Alternatively, the 
packet monitor and multicast manager may be located 
elsewhere in the computer network. In yet another al- 
ternative, packet tracking, or parts of it, is performed by 

25 the receivers themselves, perhaps at the receivers' 
sites. 

[0016] In one embodiment of the present invention, 
the multicast manager is capable of dynamically chang- 
ing the maximum number associated with each receiver. 

30 This allows the unacknowledged packet window to 
adapt to changing network transmission conditions. Al- 
ternatively, the maximum number associated with each 
receiver may be a predetermined, immutable number. 
[0017] In one embodiment of the present invention, 

35 the multicast manager controls retransmission of the un- 
acknowledged packets. In this embodiment, if a given 
packet remains unacknowledged by at least one receiv- 
er past a certain period of time, the packet is retransmit- 
ted and acknowledgment of its receipt retracked. 

40 [0018] The foregoing has outlined, rather broadly, 
preferred and alternative features of the present inven- 
tion so that those skilled in the art may better understand 
the detailed description of the invention that follows. Ad- 
ditional features of the invention will be described here- 

45 inafter that form the subject of the claims of the inven- 
tion. Those skilled in the art should appreciate that they 
can readily use the disclosed conception and specific 
embodiment as a basis for designing or modifying other 
structures for carrying out the same purposes of the 

so present invention. Those skilled in the art should also 
realize that such equivalent constructions do not depart 
from the spirit and scope of the invention in its broadest 
form. 

ss Brief Description of the Drawings 

[0019] For a more complete understanding of the 
present invention, reference is now made to the follow- 
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ing descriptions taken in conjunction with the accompa- 
nying drawings, in which: 

FIGURE 1 illustrates an embodiment of a packet 
network providing a suitable environment for a sys- 
tem constructed according to the principles of the 
present invention; 

FIGURE 2 illustrates a block diagram of an exem- 
plary computer providing an environment within 
which the system of present invention may be em- 
ploy od and implemented and 
FIGURE 3 illustfHtcs a block diagram of an embod- 
iment cA a system constructed according to the prin- 
ciples ol the oresont nvention 

Detailed Poicftpttoo 

[0020] Rclcirr*3 iritniiy <o FIG JRE 1, illustrated is an 
embodiment o» a packet network generally designated 
1 00, providing h suitable environment for a system con- 
structed accor Jhicj to the pi maples of the present inven- 
tion. The packet network 10C eg , the Internet, facili- 
tates the transmission of dal* in the form of data pack- 
ets, or datagrams between n sender and a single re- 
ceiver, in the case of a unicaol or between a sender and 
a plurality of rocervors as with a multicast. The packet 
network 100 includes a sender 1 30. such as a personal 
computer (PCi that is coupled to a data storage device 
135, e.g.. an external hard disk The system of the 
present invention is not limited tor use with a data stor- 
age device such as external physical devices or even 
the presence of such devices physically connected to 
the sender 130. The system of the present invention 
contemplates that the sender 1 30 is able to access a 
data storage device at either the sender 1 30 or at a re- 
mote location, or both. 

[0021] The sender 1 30 is also coupled to an access 
node 1 40 that provides a gateway to the packet network 
100. The access node 140 may be a packet network 
service provider, such as an Internet service provider 
(ISP), and is shown coupled to a data storage device 
1 45 analogous to the data storage device 1 35 The pres- 
ence of the access node 140 is not necessary to the 
practice of the present invention as the sender 130 is 
equipped to communicate directly to the packet network 
100 without requiring an intermediate interlace. A plu- 
rality of receivers 1 50 are also coupled to the packet 
network 100. The plurality of receivers 150 are typically 
communication devices, such as PCS. 
[0022] The sender 1 30 communicates with the plural- 
ity of receivers 150 by sending data packets via the 
packet network 100. Further information about packet 
network architectures and transmission of data packets 
may be found in 'Data Network Design," by Darren L. 
Spohn, McGraw-Hill, Inc. (1993). which is incorporated 
herein by reference. 

[0023] Turning now to FIGURE 2, illustrated is a block 
diagram of an exemplary computer, generally designat- 



ed 200, providing an environment within which the sys- 
tem of present invention may be employed and imple- 
mented. The computer 200 includes processing circuitry 
210, e.g., having at least one conventional processor, 

5 conventional volatile memory 220, e.g. , random access 
memory, and nonvolatile memory 230, e.g., a hard disk 
drive. The processing circuitry 210, volatile memory 220 
and nonvolatile memory 230 are associated with each 
other and cooperatively operate to execute the system 

io of the present invention. The computer 200 may further 
include an input/output device 240, such as a keyboard, 
and a display device 250, such as a video monitor. The 
keyboard may be used to control the execution of the 
process associated with the system of the present in- 

is vention in the computer 200, and a video monitor may 
be used to view the results thereof. 
[0024] The principles of the present invention are not 
limited to a particular processing environment, but may 
be implemented in any processing system architecture, 

20 including, without limitation, microcomputers, e.g., per- 
sonal and mainframe computers. Those skilled in the art 
should readily appreciate that the present invention may 
be also implemented in hardware. Conventional 
processing system architecture is discussed in "Com- 

25 puter Organization and Architecture/ by William Stall- 
ings, MacMillan Publishing Co. (3rd ed. 1993), which is 
incorporated herein by reference, and conventional 
processing system network design is discussed in "Data 
Network Design," by Darren L. Spohn, McGraw-Hill, Inc. 

30 (1993). 

[0025] As mentioned previously, there has been ef- 
forts to develop congestion control methodologies for 
multicast. These efforts, however, have been focused 
primarily in the areas of video and audio multicast trans- 

35 missions. Typically, in audio and video multicasts, it 
does not matter significantly if the receivers do not re- 
ceive every data packet that was transmitted by the 
sender, i.e., some of the transmitted data is lost. The 
sender and receivers in response to network conges- 

40 tion, will adjust their subscription, i.e., sending or receiv- 
ing, of data packets. The congestion control methodol- 
ogy employed is a regime of receiving less data packets. 
For example, upon detection of congestion in the packet 
network, the sender will adjust the data packets trans- 

45 mission by transmitting only -high priority" packets. The 
receivers, in turn, instead of receiving all the data pack- 
ets, will only subscribe to receive the high priority pack- 
ets. To illustrate, in video multicast, the high priority 
packets are distinguished from the regular packets in 

so that the receivers will be able to still form a coarse pic- 
ture, Le., lower resolution, with the high priority packets. 
[0026] For reliable unicast communications in packet 
networks, such as the Internet, a window mechanism 
method has been widely used as the method for the dual 

55 purposes of error and congestion control. The window 
mechanism controls congestion by keeping the number 
of outstanding packets, i.e., those packets that have 
been transmitted but have not been received and those 
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packets that have been received but their acknowledg- 
ments have not been received by the source, below a 
defined maximum number of W, called, for purposes of 
the present description, a "window size." For unicast 
communications, this methodology has been successful 
in preventing congestion in packet networks. 
[0027] The window mechanism for unicast communi- 
cations has been often described or implemented using 
a sliding window embodiment. The sliding window em- 
bodiment, which is for example used in a transport con- 
trol protocol (TCP), is based on an implicit assumption 
that can present a limitation in its use for congestion con- 
trol. This assumption is that the acknowledgments of 
packets are not accepted unless all prior packets that 
were transmitted earlier in time have been acknowl- 
edged. This ordered acknowledgment requirement 
makes the sliding window embodiment of the window 
mechanism inconvenient for cases where acknowledg- 
ments are also accepted out of order. 
[0028] The present invention discloses a method for 
congestion control for multicast communications across 
a packet network, such as the Internet, using a multicast 
window mechanism. In order to describe this multicast 
window mechanism; the use of a token pool embodi- 
ment is preferred over a sliding window embodiment in 
order to easily accommodate out of order acceptance 
of acknowledgments, where desired. Of course, the 
same scheme can be described or implemented using 
other possible embodiments. 

[0029] In the token pool illustration for a window 
mechanism, it is assumed that a pool of a certain defined 
number (W) of tokens, referred to as the window size, 
is established. Data packets are not permitted to be 
transmitted unless there is a token in the token pool. The 
sender removes a token from the pool upon transmitting 
each new data packet. Upon receiving an acknowledg- 
ment from the receiver that the data packet has been 
received, the sender places the removed token back in- 
to the token pool. The sender will also place the re- 
moved token back into the token pool, when the sender 
has not received an acknowledgment and it has con- 
cluded that the packet should be considered as lost, e. 
g. t if out of sequence acknowledgment are received or 
if a time limit has been exceeded. Those skilled in the 
art should appreciate that the methods for determining 
if a data packet has been tost are protocol dependent. 
[0030] Consider the ith receiver in the multicast group 
and let V\M be the desired window size in a hypothetical 
unicast communication between the source and the ith 
receiver. The average transmission rate from the source 
to the ith receiver in such a hypothetical unicast com- 
munication would have oeen: 

R_i = WJ/TJ 

where T_i denotes the rverage round trip time for com- 
munication between ths source and the ith receiver. The 



window mechanism for multicast congestion control is 
now described using a token pool embodiment. Two 
types of window mechanism for multicast are presented, 
one of which is actually recommended since it provides 

s superior performance. 

[0031] In the first type of multicast window mecha- 
nism, which is referred to as method A, a single token 
pool is used with size W_min, /.a.the smallest of the 
window sizes W_i of all the receivers. A token from this 

10 token pool is consumed each time a packet is transmit- 
ted, and whenever the acknowledgment for the trans- 
mitted packet is received by the sender from all of the 
receivers, a token is returned to the token pool. Since 
the receiver with the longest round trip time, T_max, 

'5 dominates, the average rate of multicast transmission 
for method A is approximately: 

FLa - W_min/T_max 

20 

[0032] In the second type of multicast window mech- 
anism (method B), one token pool is established for 
each receiver. In this method, a packet may not be sent 
until a token is available in every pool- When a packet 

2S is sent, one token is consumed from each pool. When 
an acknowledgment for a packet is received from the ith 
receiver, a token will be returned to the corresponding 
pool, without waiting for that packet to be acknowledged 
by the other receivers. It can be shown that the average 

30 rate of multicast transmissions for method B is approx- 
imately: 

R_b = minimum R_J = minimum W_i/TJ 

35 

and assuming minimization is achieved for i = k, it can 
be concluded that, 

40 R_b = W_k/T_k = R_a. (T_max/T_k). (W_k/W_min) 

[0033] It should be readily appreciable that method B, 
i.e. , the method of using one token pool for each receiver 
is the preferred approach. The average rate of transmis- 

45 sions in this method is almost equal to the rate of unicast 
transmissions to the slowest receiver (receiver k in the 
above formula), which is larger than the average rate of 
transmissions in method A by a factor of (T_max/T_k) 
(W_k/W_min). This means that if, e.g., the longest round 

so trip time among the receivers is 10 times the round trip 
time of the slowest receiver, i.e., receiver k, then the av- 
erage rate of transmission in method B will be at least 
1 0 times more than method A. 

[0034] For the above reason, we have disclosed 
ss method B as the preferred multicast window mecha- 
nism. The essence of this preferred multicast window 
mechanism is that it separately controls the number of 
outstanding packets for each receiver i and keeps it be- 
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low the corresponding window size W_i. By outstanding 
packets of a receiver i, what is meant is the number of 
packets sent by the sender, for which the sender is still 
waiting to receive an acknowledgment from receiver L 
[0035] Keeping the number of outstanding packets for 
each receiver i in the multicast group below the corre- 
sponding window size W J is the essence of this inven- 
tion. Those skilled in the art should readily appreciate 
that the particular token pool embodiment just described 
above may be substituted by other schemes. These oth- 
er schemes, which may or may not involve token pools 
but would accomplish the same objective, ie. t would 
keep the number of outstanding packets for each receiv- 
er i in the multicast group below the corresponding win- 
dow size W_i, are within the broad scope of the present 
invention. 

[0036] Turning now to FIGURE 3, illustrated is a block 
diagram of an embodiment of a system constructed ac- 
cording to the principles of the present invention. The 
system controls congestion due to a multicast in a com- 
puter network 300. The system includes a multicast 
manager 310, associated with a multicast sender 315, 
that receives from a receiver (one of which is designated 
320) an acknowledgment packet (one of which is shown 
and designated 350) containing a delivery status of in : 
dividual data packets (one of which is shown and des- 
ignated 370) of a multicast delivered to the receiver 320. 
The sender 315 also includes a number of token pools 
(one of which is shown and referenced 340) one for each 
of the receivers 320 to which the multicast is transmitted. 
The system also includes a packet monitor 330, asso- 
ciated with the sender 31 5, that analyzes the delivery 
status and modifies the number of tokens in the token 
pools 340 associated with each of the receivers 320. 
While the multicast manager 310 and packet monitor 
330 are only illustrated in the sender 315 in the present 
embodiment, there are possible embodiments where 
these functionalities or their equivalents may be execut- 
ed at the receivers 320 or at other points of the network. 
[0037] The size of the token pool 340 associated with 
the ith receiver 320, W_i, determines the maximum 
number of data packets 370 that may be outstanding to 
the ith receiver 320 at any point of time, i.e., the maxi- 
mum number of data packets 370 that may be transmit- 
ted by the sender 315 while it still awaits their acknowl- 
edgments 350. The multicast manager 310 controls the 
transmission of new data packets 370 to prevent the 
number of data packets 370 that may be outstanding to 
the ith receiver 320 from exceeding W_i. The sender 
315 may not transmit any new data packets 370 to any 
particular receiver 320 unless there is a token available 
in every token pool 340. When the sender 31 5 transmits 
a new data packet 370, the packet monitor 330 removes 
a token from ail of the token pool 340. Once an acknowl- 
edgment for a given data packet 370 is returned from 
the ith receiver 320, the packet monitor 330 returns one 
token to the corresponding token pool 340 associated 
with the ith receiver 320. Those skilled in the art should 



appreciate that alternative methods to adjust the size of 
the token pool 340, such as adding tokens to the token 
pool 340 when data packets 370 are transmitted and 
removing tokens when acknowledgments are received, 

s may also be implemented. Also, the acknowledgment 
packet 350 typically contains a bit (having a state that 
is a function of the delivery status) 360 corresponding 
to each of the individual data packets 370. Those skilled 
in the art should understand that an acknowledgment 

10 packet 350 does not necessarily have to acknowledge 
a single data packet 370. As an alternative, an acknowl- 
edgment packet 350 may be used to report the delivery 
status of a number of data packets 370, in which case 
it may include one status bit per packet 370. It may be 

15 required that a receiver 320 sends an acknowledgment 
packet 350 after each data packet 370 is received, or 
alternatively, acknowledgment packets may be sent 
less frequency. 

[0053] Following the reception of the acknowledg- 
20 ment packets 350, the sender 315 measures the round 
trip time of each data packet 370. A received acknowl- 
edgment packet 350 may contain acknowledgments for 
more than one data packet 370. The sender 315 then 
proceeds to update both the round trip time estimate and 
25 the time-out for the corresponding receiver 320. The 
time-out is a time counter that is initialized when a data 
packet 370 is transmitted and is subsequently de- 
creased until an acknowledgment packet 350 for that 
data packet 370 is received. Those skilled in the art are 
30 aware that time-out counters may be implemented 
whereby the time measurement is increased. The time- 
out value is at least the round trip time estimate for the 
corresponding receiver 320. 

[0039] A data packet 370 may be considered lost if an 

3S acknowledgment packet 350 is not received by the 
sender 315 at the expiration of the time-out for that re- 
ceiver 320. Also, a data packet 370 may be considered 
lost, even before the time out, if the acknowledgment 
packet 350 of another data packet 370, that was trans- 

40 mitted after the data packet 370 under consideration, 
has been received by the sender 31 5. The data packet 
370 loss is then registered by the sender 315 and the 
packet monitor 330 returns a token to the token pool of 
that particular receiver 320. 

45 [0040] As previously mentioned, the sender 31 5 or re- 
ceivers 320 are generally general purpose computers, 
as illustrated in FIGURE 2. The general purpose com- 
puter is capable of storing and executing a sequence of 
instructions to operate the system for controlling con- 

so gestion due to a multicast in a computer network. The 
multicast manager 310 and packet monitor 330, for in- 
stance, are embodied in a sequence of instructions ex- 
ecutable on the processor of the general purpose com- 
puter. Alternatively, the present invention may be em- 

ss bodied in dedicated or hardwired discrete or integrated 
circuitry. 

[0041] In the above description of the window mech- 
anism, it is assumed that the window size W_i associ- 
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ated with each receiver has a fixed value. Alternatively, 
it is also possible to adjust the window size W_i of each 
receiver based on variations in the network traffic load 
in accordance with some algorithm. The window mech- 
anism, however, will still continue to operate in the fash- 
ion disclosed by the present invention and its operation 
is independent of whether the window size W_i is 
changed or kept constant. 

[0042] From the above, it is apparent that the present 
invention provides a system and method for using a win- 
dow mechanism to control transmission of a multicast 
in a computer network in order to curb congestion. The 
system includes: (1 ) a packet monitor that tracks, for 
each receiver of the multicast, unacknowledged packets 
transmitted to each receiver and (2) a multicast manag- 
er, associated with the packet monitor, that controls 
transmission of further packets of the multicast to pre- 
vent the unacknowledged packets transmitted to any of 
each receiver from exceeding a maximum number. 
[0043] Although the present invention has been de- 
scribed in detail, those skilled in the art should under- 
stand that they can make various changes, substitutions 
and alterations herein without departing from the spirit 
and scope of the invention in its broadest form. 
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pool for said each receiver is initialized to zero, said 
packet monitor placing a token in each ol said token 
pools when a packet is transmitted and removing a 
token from one of said token pools when a receiver 
corresponding to said one of said token pools ac- 
knowledges receiving said packet. 

5. A method of controlling transmission of a multicast 
in a computer network, comprising the steps of: 

tracking, for each receiver of said multicast, un- 
acknowledged packets transmitted to said 
each receiver; and 

controlling transmission of further packets of 
said multicast to prevent said unacknowledged 
packets transmitted to any of said each receiver 
from exceeding a maximum number associat- 
ed with said each receiver. 

6. The method as recited in Claim 5,wherein said step 
of tracking comprises the step of establishing a to- 
ken pool for said each receiver, said multicast man- 
ager preventing a number of tokens in each said 
token pool from being outside a particular range. 

7. The method as recited in Claim 6, wherein said step 
of tracking comprises either the steps of: 



1. A system for controlling transmission of packets of 

a multicast in a computer network, comprising: 30 

a packet monitor that tracks, for each receiver 
of said multicast, unacknowledged packets 
transmitted to said each receiver; and 
a multicast manager, associated with said 35 
packet monitor, that controls transmission of 
further packets of said multicast to prevent said 
unacknowledged packets transmitted to any of 
said each receiver from exceeding a maximum 
number associated with said each receiver. 40 

2. The system as recited in Claim 1 wherein said pack- 
et monitor establishes a token pool for said each 
receiver, said multicast manager preventing a 
number of tokens in each said token pool Irom being 45 
outside a particular range. 

3. The system as recited in Claim 2 wherein said token 
pool for said each receiver is initialized with a 
number o1 tokens equaling said maximum number 50 
associated with said each receiver, said packet 
monitor removing a token from each of said token 
pools when a packet is transmitted and replacing a 
token in one of said token pools when a receiver 
corresponding to said one of said token pools ac- 
knowledges receiving said packet. 

4. The system as recited in Claim 2 wherein said token 



initializing said token pool for said each receiv- 
er with a number of tokens equaling said max- 
imum n umber associated with said each receiv- 
er, 

removing a token from each of said token pools 
when a packet is transmitted; and 
replacing a token in one of said token pools 
when a receiver corresponding to said one of 
said token pools acknowledges receiving said 
packet, or the steps of: 

initializing said token pool for said each re- 
ceiver to zero; 

placing a token in each of said token pools 
when a packet is transmitted; and 
removing a token from one of said token 
pools when a receiver corresponding to 
said one of said token pools acknowledges 
receiving said packet. 

8. A computer network, comprising: 

a multicast sender; 

a plurality of receivers that receive said multi- 
cast from said multicast sender; and 
a system for controlling transmission of a mul- 
ticast in a computer network, including: 
a packet monitor that tracks, for each of said 
plurality of receivers, unacknowledged packets 
transmitted to said each of said plurality of re- 
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ceivers, and 

a multicast manager, associated with said 
packet monitor, that controls transmission of 
further packets of said multicast to prevent said 
unacknowledged packets transmitted to any of s 
said plurality of receivers from exceeding a 
maximum number associated with said each 
receiver. 

9. The network as recited in Claim 8, wherein said 10 
packet monitor establishes a token pool for said 
each of said plurality of receivers, said multicast 
manager preventing a number of tokens in each 
said token pool from being outside a particular 
range. 15 

10. The network as recited in Claim 9, wherein said to- 
ken pool for said each of said plurality of receivers 
is initialized with a number of tokens equaling said 
maximum number associated with said each receiv- 20 
er, said packet monitor removing a token from each 

of said token pools when a packet is transmitted and 
replacing a token in one of said token pools when 
a of said plurality of receivers corresponding to said 
one of said token pools acknowledges receiving 25 
said packet. 

11. The network as recited in Claim 9, wherein said to- 
ken pool for said each of said plurality ol receivers 

is initialized to zero, said packet monitor placing a 30 
token in each of said token pools when a packet is 
transmitted and removing a token from one of said 
token pools when a of said plurality of receivers cor- 
responding to said one of said token pools acknowl- 
edges receiving said packet. 35 
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